Job Documentation, step Docs: sync website on d9de425 wanted to post the following:

View the site here

This comment will be updated on new commits.

Job Coverage, step Generate coverage on af5b335 wanted to post the following:

Framework coverage

Diff coverage report

Full coverage report

Modules coverage

Coverage did not change

Full coverage reports

This comment will be updated on new commits.

Here's a Claude review

Overall Assessment

The implementation is well-structured and the core algorithms (Möller-Trumbore ray intersection,
solid-angle fallback, BFS re-orientation, yz acceleration grid) are all sound. One real bug was
found, along with two minor correctness issues and a few design observations.

Bug: Negative t Returns Ambiguous Instead of Miss

File: framework/src/utils/STLManifold.C, rayIntersectsTriangle()

const Real t = inv_determinant * (edge2 * q);
if (t <= _surface_tolerance)
    // Hits too close to the ray origin are treated as ambiguous boundary situations.
    return RayIntersection::Ambiguous;

t <= _surface_tolerance covers two distinct cases with different correct results:

Currently both map to Ambiguous, which causes containsBySolidAngle() (an O(n) scan of all
triangles) to be invoked for every triangle that straddles the query point's x-coordinate but
whose actual plane hit is in the −x direction. In contains(), an Ambiguous result immediately
returns, abandoning the parity loop early, so these misfires produce a correct but very expensive
result.

The pre-filter tri.bbox.max()(0) < point(0) - _surface_tolerance does not exclude this case —
a triangle whose bounding box straddles the query point's x can still have its plane intersection
at a negative t.

Fix:

const Real t = inv_determinant * (edge2 * q);
if (t < 0.0)
    return RayIntersection::Miss;
if (t <= _surface_tolerance)
    return RayIntersection::Ambiguous;

Minor: !probe Check Has Inverted Logic

File: framework/src/utils/STLManifold.C, parse()

probe.read(header.data(), header.size());
if (!probe && file_size >= header.size())
    mooseError("Failed while reading STL file '", file_name, "'.");

std::ifstream::read() sets failbit on any short read (including EOF), so !probe fires for
files smaller than 84 bytes regardless of the intent. The file_size >= header.size() guard
happens to work because file_size is captured before the read, but the logic is subtle.
Using gcount() makes the intent explicit:

if (probe.gcount() < static_cast<std::streamsize>(header.size()) && file_size >= header.size())
    mooseError("Failed while reading STL file '", file_name, "'.");

Minor: Binary Detection Can Misfire on an 84-Byte ASCII File

File: framework/src/utils/STLManifold.C, parse()

const auto expected_size = static_cast<std::size_t>(84ull + 50ull * triangle_count);
parse_as_binary = expected_size == file_size;

If bytes 80–83 of the ASCII file are all zero (common when the solid name is short or absent),
triangle_count reads as 0 and expected_size becomes 84. An ASCII file that is exactly 84
bytes long is then parsed as binary and immediately fails with "does not contain any triangles."
Adding a zero-count guard eliminates the ambiguity:

parse_as_binary = triangle_count > 0 && expected_size == file_size;

Design Observations

All MPI ranks read the STL file.
generate() runs on every rank and constructs STLManifold (which opens and reads the file) on
each. For thousands of ranks on large parallel systems this causes a file-system storm. A common
MOOSE pattern is to restrict file I/O to rank 0 and broadcast the parsed data, though the current
behavior is consistent with other mesh generators in the framework.

surface_tolerance is an absolute tolerance with a very small default.
The manifold validation uses surface_tolerance = 1e-10 for vertex quantization. If the STL file
exports vertices with floating-point noise at the ~1e-9 level (not uncommon for some CAD
exporters), coincident vertices will not be stitched and the non-watertight error will fire
unexpectedly. The documentation and parameter description should emphasize that this value must be
chosen relative to the actual geometry scale.

No warning when block_id already exists.
If the user specifies a block_id that is already assigned to elements outside the STL manifold,
those elements are silently left unchanged while elements inside the manifold are overwritten. This
is consistent with SubdomainBoundingBox and similar generators, but a mooseWarning when the
target block already has elements could prevent user confusion.

Summary

Job Precheck, step Clang format on cced4a0 wanted to post the following:

Your code requires style changes.

A patch was auto generated and copied here
You can directly apply the patch by running, in the top level of your repository:

curl -s https://mooseframework.inl.gov/docs/PRs/32764/clang_format/style.patch | git apply -v

Alternatively, with your repository up to date and in the top level of your repository:

git clang-format 4e53b3bd56df4ef82d088b21f4bdbf48c201469f

Job Test, step Results summary on d9de425 wanted to post the following:

Framework test summary

Compared against 4e53b3b in job civet.inl.gov/job/3786076.

Added tests

Modules test summary

Compared against 4e53b3b in job civet.inl.gov/job/3786076.

No change